The invention relates to a method for managing transmissions of multimedia data via an internet-type network with the aid of smart cards connected to terminals provided with a smart card reader.
The invention relates more particularly to the management of telephone or videophone transmissions via an internet-type network.
The invention also relates to a smart card for implementing this method.
The aforementioned transmissions can be done either entirely on the internet-type network or partly over this network and partly over a standard telephone network (for instance of the switched type), via a hardware gateway and suitable software.
To define the concepts, and without in any way limiting the scope of the invention, the method will be described in the context of the preferred application, that is, telephone calling via an internet network. Within the scope of the invention, the term xe2x80x9cinternet networkxe2x80x9d must be understood in its most general sense. Besides the internet itself, it pertains to private business networks or the like of the type known as xe2x80x9cintranetxe2x80x9d, and networks extending them to the outside, of the type known as xe2x80x9cextranetxe2x80x9d, and in general any network in which data exchanges are done in accordance with an internet-type protocol. In the following description, such a network will be generically called an xe2x80x9cinternet networkxe2x80x9d.
The term xe2x80x9cterminalxe2x80x9d must also be understood in a general sense. The aforementioned terminal can in particular comprise a personal computer operating under various operating systems, such as Windows or UNIX (both of these being registered trademarks). It can also comprise a workstation, portable computer, or dedicated card terminal.
Given the spectacular development of the internet network in the last five years, an increasing number of terminals are connected to this network, especially for the sake of being linked to remote servers of the web type. There are limitations in terms of the data traveling over these links that make up the web of the internet network. However, these limitations are not primarily linked to the nature of the data but instead to the speed that these links allow. The recent installation of high-speed links (cable, ASDL, satellite links, ISDN, etc.) nevertheless make it possible to carry data of the multimedia type and to process these data in real time.
It is also of particular interest to have telephone communications, even videophone communications, travel over the internet network. Transmitting the data themselves does not present any particular problems. They can be processed by the protocols typically used on this type of network. The management of the communications, however, does present specific problems, especially problems associated with what in conventional telephony is called xe2x80x9csignalingxe2x80x9d. In general, this concept designates such operations as calling a correspondent, accepting a call, beginning and ending a conversation, ringing, disconnection, etc.
In the 1990s, a great many systems and types of software for making telephone calls via the internet network have been proposed.
The first telephone for the internet, called xe2x80x9cInternet Phonexe2x80x9d (registered trademark), was developed by the company known as Vocaltec in 1995. By now, dozens of products are known: xe2x80x9cWebPhonexe2x80x9d, xe2x80x9cNetMeetingxe2x80x9d put out by Microsoft (both of these are registered trademarks), and so forth.
The resultant state of the art is accordingly distinguished by great diversity and a lack of standards, or at least de facto standards. It follows that these products are not interoperable.
However, the following current trends can be observed:
a) use of a port of the TCP type to achieve pseudo-signaling (notification of a call, identification of the caller for the sake of accepting or rejecting the call, etc.);
b) compression of the audio signal, for instance using the method known as UIT-T G723 (Union Internationale des Txc3xa9lxc3xa9communications) from 5.3 kbps to 6.3 kbps;
c) broadcasting sound using the RTP protocol (Real Time Protocol), meeting the specification RFC 1889, which it in turn uses the UDP transmission protocol (for User Datagram Protocol) and dated pdus (for Protocol Data Units), and which is associated with RTCP control protocol (for Real Time Transport Control Protocol); and
d) identifying the called party by its IP address, where numerous servers make it possible to assign, to a fixed mail address, an IP address issued by a PPP server of a service provider (ISP, for Internet Service Provider), such as a server known by the symbol ICQ for example.
When communications must leave the internet network, internet telephony gateways or ITGs make it possible to connect a public switched telephone network or RTC, known in English as PSTN. The H323 protocol which defines the format of packets used in local networks and in an ISDN network seems to be becoming the dominant standard for call control protocols or CCPs.
Internet telephony presents three main types of problems:
a) locating the subscriber in the network, that is, establishing a relationship between an IP address (of an information processing machine) and the subscriber;
b) managing the signaling of a telephone call (calling the correspondent, acceptance of the call, beginning of a conversation, end of a conversation): this function is performed by what is called a proprietary protocol (generally called a proprietary signaling protocol or PSP) for calls of the internet/internet type, or by a particular protocol (the aforementioned CCP) that is coming to be the standard for calls of the internet/PSTN type, the signaling being done by means of a TCP connection which will hereinafter be called the signaling channel or CS; and
c) the exchange of a multimedia data stream: The protocol adopted is generally the protocol known as RTP (for real time protocol, corresponding to the aforementioned specification RFC 1889), and the exchange of multimedia data is done through a data channel, while the information is transported by the aforementioned UDP protocol.
To make a telephone conversation on the internet, the caller and the called party must both use the same software. FIG. 1 schematically illustrates the main modules that make up telephony software (LT), such as the xe2x80x9cNetMeetingxe2x80x9d software mentioned above. Schematically, a conventional telephony software and the architecture of the associated transmission system include the following subassemblies:
a) a subscriber profile (PA), which contains a set of information making it possible to identify a subscriber;
b) a listing protocol (PE) which performs the listing of a subscriber in a directory server (SAxe2x80x94identified by a particular port number or TCP, such as port No. 389);
c) a locating protocol (PL), which performs the function of looking up a subscriber on the basis of this identifier (in general, e-mail), this function being implemented by means of a connection to the directory server (SA);
d) a signaling channel (CS), which employs a proprietary signaling protocol (PSP), which manages a telephone call through a TCP connection to a particular port (No. 1503 for NetMeeting); and
e) a data channel (CD), which manages the exchange of data in real time (sound and/or images) with the aid of a data exchange protocol, such as RTP.
Optionally, the internet telephony software can send a call to a subscriber of the standard telephone network, using a call control protocol (CCP), by means of a TCP connection (to port No. 1731, in the case of the xe2x80x9cNetMeetingxe2x80x9d software).
FIG. 1 accompanying the present description schematically illustrates the architecture of a telephony system 9 via the internet network RI, according to the prior art, and using telephony software of the type that has just been described.
In this figure, two terminals 9a and 9b have been shown schematically, reduced only to the telephony software with which they are equipped, 90a and 90b, respectively.
The components of these types of software include one listing protocol PE 900a and 900b for each terminal 9a and 9b, respectively, associated with a respective subscriber profile (PA) 903a and 903b and a locating protocol PL, 901a and 901b, respectively. A subscriber profile PA includes a basic identifier of a subscriber, Aa or Ab, generally known as a xe2x80x9cUserIDxe2x80x9d, and various data which will be specified hereinafter that identify this subscriber more completely.
The listing protocol PE, 900a or 900b, enables the subscribers Aa and Ab associated with the terminals 9a and 9b, respectively, to list themselves in a directory server 91 connected to the internet network RI. The listings are done using identification data contained in the aforementioned subscriber profiles PA, 903A and 903B, respectively.
When one wishes to make a communication between two subscribers, one must first proceed to a phase of locating the called subscriber. For instance, if the terminal 9a is to be put into communication with the terminal 9b, then the IP address of the terminal 9b in the internet network RI must be known.
These processes per se are common to conventional telephony in a purely switched network. A call number is assigned to each subscriber, and this number is listed in one or more directories.
However, using an internet network to telephone transmissions between subscribers, or even between terminals, imposes specific constraints.
First, it would appear useful to briefly recall the main characteristics of the protocols for communication over networks.
The architecture of communication networks is described by various layers. By way of example, the OSI standard (for Open System Interconnection) defined by the ISO includes seven layers, which range from what are known as lower layers (such as the xe2x80x9cphysicalxe2x80x9d layer, which involves the physical transmission substrate) to what are known as high, or upper, layers (such as the xe2x80x9capplicationxe2x80x9d layer), passing through intermediate layers, especially the xe2x80x9ctransportxe2x80x9d layer. A given layer offers its services to the layer that is immediately above it, and requests other services, via suitable interfaces, from the layer that is immediately below it. The layers communicate with the aid of primitives. They can also communicate with layers of the same level. In certain architectures, various layers may not be present.
In an environment of the internet type, the layers are five in number, and more precisely, ranging from the highest to the lowest layer, they are: the application layer (xe2x80x9chttpxe2x80x9d, xe2x80x9cftpxe2x80x9d, xe2x80x9ce-mailxe2x80x9d, etc.), the transport layer (xe2x80x9cTCPxe2x80x9d), the network addressing layer (xe2x80x9cIPxe2x80x9d), the data link layer (xe2x80x9cPPPxe2x80x9d, xe2x80x9cSlipxe2x80x9d, etc.), and the physical layer.
In the prior art, the subscribers Aa and Ab use internet terminals 9a or 9b, which have a fixed IP address or a variable one when an internet service provider or ISP is used.
A first disadvantage is the fact that an IP address is not associated with a subscriber but rather with an information processing system connected to the internet network. Even in the case where the information processing system is provided with a fixed address, there is no correspondence a priori between an IP address and a physical person. In a practical sense, to establish such a relationship, the subscriber makes a connection with the directory server SA 91 (which can for example be of the IRC type, for Internet Relay Chat). This server associates the IP address of the subscriber to the subscriber identifier or UserID. The identifier is generally his e-mail address, but an arbitrary pseudonym can also be used.
This association is generally not authenticated, so that the service (typically free) can be used as conveniently as possible. However, this arrangement is not exempt from disadvantages, especially for what called xe2x80x9csensitivexe2x80x9d applications.
One of the first constraints encountered is accordingly to locate a subscriber in the internet network RI, that is, to establish a correspondence between a fixed identifier and an IP address.
Locating a subscriber on the internet network RI, that is, establishing the aforementioned correspondence, presupposes that the subscriber was already listed in the directory server SA.
The address of the subscriber in the internet network accordingly comprises a pair: address SA and UserID. In the usual way, the term xe2x80x9csubscriberxe2x80x9d means a xe2x80x9cphysicalxe2x80x9d entity. By extension, it can be a function. However, hereinafter, xe2x80x9csubscriberxe2x80x9d will be used in its common sense, without in any way limiting the scope of the invention.
In practical terms, a subscriber indicates his location in the internet network RI by a voluntary act, by furnishing the (directory) server his current IP address, using the aforementioned listing protocol PE.
This operation requires that the terminal 9a or 9b have a specific (or applications) software, issued by the service provider, in this case the software PE, 900a or 900b, and personalized with a particular subscriber profile PA, 903a or 903b. 
As has been indicated, besides the basic identifier for the subscriber (UserID), the subscriber profile PA, 103a or 103b, includes a set of information furnished to the directory server SA 91 at the time the subscriber was listed, for example:
the address of the directory server (SA);
the subscribers (identified by their UserIDs) with which the user is willing to enter into communication, or to whom he wants to notify his location in the network; and
the information that he is willing to make public in the directory server (such as name, nationality, contacts sought, and so forth). To contact a correspondent through the internet network RI, this correspondent being duly listed, it is necessary to know his IP address. This information is obtained using the directory server SA 91 and the locating protocol PL, 901a or 901b, respectively.
It should be noted that the subscriber profile PA is by its nature specific to the subscriber, but it can also depend on characteristics of the directory server SA, especially the type and nature of the information that must be furnished to him or that he can accept.
It should finally be noted that the PL protocol 901a or 901b, like the PE protocol 900a or 900b, is proprietary, since it addresses a directory server SA 91 that is a priori non-standardized or does not meet universally recognized standards. The PE and PL protocols of terminals must be compatible with the corresponding protocols in the directory server SA 91, 910 and 911, respectively.
These two characteristics represent additional disadvantages.
To summarize the above review, if a calling subscriber PA is to be able to locate a called subscriber Ab and be located by the latter in turn, the terminal he uses, such as 9a, must store specific software 900a or 900b, 901a or 901b, which make it possible to use the PE and PL protocols. It must also be necessary for the terminal to store data pertaining to its subscriber profile PA 903a. This comment applies similarly to the terminals of other subscribers, such as the terminal 9b. 
In other words, the terminal 9a or 9b used by an arbitrary subscriber Aa or Ab is also specific, in the sense that if this subscriber wishes to change terminals he must, in the new terminal used, retrieve at least the software or programs associated with the PL protocol, by acknowledging that he had performed a preliminary listing phase in the first terminal by calling the protocol PE and by furnishing his profile PA to the directory server SA. In fact, the presence of the protocol PL is necessary in order to address the directory server SA 91 and to have access to the data recorded in it, in particular the IP addresses of the correspondence sought and their profiles PA.
The terminals 9a or 9b must also be provided each with two additional programs, also of proprietary type: the signaling protocol PSP, 902a or 902b, and the data exchange protocol RTP mentioned above (or a similar protocol), 905a or 905b. The modules associated with the PSP protocol correspond with one another by way of the signaling channel CS, through the internet network RI. In the same way, the modules associated with the RTP protocol correspond with one another by way of the data channel CD, through the internet network RI.
Finally, if the telephone communications must depart from the internet network RI to the standard switched network 93, it is necessary to provide the aforementioned call control protocol or CCP mentioned above (or a similar protocol), 904a or 904b, which is also proprietary. It is also necessary to provide one or more gateways of the ITG type mentioned above, represented by the unique reference numeral 92, between the module 904a associated with the CCP protocol, and the PSTN network 93. A subscriber telephone 95 communicates with the PSTN via a central conventional PBX 94, or any similar system. The communications between the gateway ITG 92 and the subscriber terminal, 9a in the example shown in FIG. 1, employ a TCP type of connection. This communications in the switched telephone network portion are done in the conventional way and there is no need to describe them again here.
It would accordingly be valuable to use non-standardized terminals to perform the phases of listing and especially of locating subscribers on the internet network RI, as well as signaling (calling the subscriber located, and so forth) and exchanging data, which would make it conveniently possible to achieve the concept called xe2x80x9cnomadismxe2x80x9d.
It would also be valuable to be able, in the signaling phase, to use a procedure for simple or mutual secure identification between the called party and the caller. Various negotiations, such as negotiations of encryption keys or operations called xe2x80x9creservationxe2x80x9d or routing paths, would also have to be capable of being done at the time of this signaling phase. In addition, in the data exchange phase, it would be valuable to be able to assure robust encryption/decryption of information, based for instance on the encryption keys negotiated beforehand. Finally, it would be valuable to be able to use pricing based on the quantity (rate) of data exchanged and/or on the quality of the routing paths put at one""s disposal, these paths having been negotiated for instance in the preceding signaling phase.
The programs associated with the aforementioned protocols PE and PL do not typically require having a large amount of memory available. The same is true for the profile data PA. Hence it is possible to conceive of recording them entirely or in part in the memory circuits of a smart card, which current technology does allow.
However, this involves a dual technical difficulty, as will be shown hereinafter, which prevents any direct communication between the internet network RI and a smart card.
First, the general architecture of a smart card-based applications system will be reviewed briefly, with reference to FIGS. 2A and 2B.
A smart card-based applications system can generally include the following main elements:
a smart card;
a host system comprising the aforementioned terminal;
a communications network, that is, the internet in the preferred application;
and an applications server connected to the internet.
FIG. 2A schematically illustrates one example of this type of architecture. The terminal 1, such as an individual computer, includes a reader 3 for a smart card 2. This reader 3 may or may not be physically integrated with the terminal 1. In the context of the invention, the terminal 1 plays the role of the terminals 9a or 9b of the system of FIG. 1. The smart card 2 includes an integrated circuit 20 whose input/output connections are flush with the surface of its substrate, to allow a supply of electrical energy and communications with the terminal 1. This terminal includes circuits 11 for access to the internet RI. These circuits can be constituted by a modem for connection to a switched telephone line or a higher-speed communication path, such as the Integrated Service Digital Network (ISDN), cable, or satellite links. The circuits 11 enable connection to the internet RI, either directly or via an internet service provider (ISP). Recourse can also be had to an intermediate system such as a proxy or an insulation system known as a firewall (or guard barrier).
The terminal 1 naturally includes all the circuits and devices necessary for its proper functioning, which have not been shown for the sake of simplifying the drawing: a CPU, random access and read-only memories, magnetic disk mass memory, disk drive and/or CD-ROM drive, and so forth.
Typically, the terminal 1 is also connected to conventional peripherals, either integrated or not, such as a display screen 5, a keyboard 6a and a mouse 6b, and 2 so forth.
The terminal 1 can be put into communication with servers or any information processing systems connected to the network RI, of which a single server 4 is shown in FIG. 2A. In the context of the invention, the server 4 comprises a directory server 91 (FIG. 1) and the terminal 1 comprises on of the systems 9a or 9b associated with a subscriber Aa or Ab. The access circuits 11 put the terminal 1 into communication with the servers 4 using a particular software 10, called a web navigator or browser. This enables access to various applications or data files that are distributed over the entire network RI, generally by a client-server mode, and in particular enables access to multimedia files.
The communication protocol for the internet network RI is selected as a function of the particular application contemplated, such as looking up web pages, transferring files, electronic mail (or e-mail), forums, news, etc.
The software architecture of the system including a terminal, a smart card reader and a smart card, is shown schematically in FIG. 2B. It is described by ISO standard 7816, which in turn includes several subsets:
ISO 7816-1 and 7816-2, pertaining to the dimensions and marking of cards;
ISO 7816-3, pertaining to the transfer of data between the terminal and the smart card; and
ISO 7816-4, pertaining to the structure of the set of orders and the format of commands.
In FIG. 2B, for terminal 1, only the layers meeting ISO standard 7816-3, identified by reference numeral 101, and an APDU order manager (ISO 7816-4), reference numeral 102 are shown. For the smart card 2, the layers meeting ISO 7816-3 are identified by reference numeral 200, and the ADPU order manager (ISO 7816-4) has reference numeral 201. The applications carry reference symbols A1, . . . Ai, . . . An, where n is the maximum number of applications present in the smart card 2.
An application Ai in the smart card 2 (FIG. 1A) conducts a dialog with the terminal 1 by means of a set of orders. This set typically has writing and reading orders. The order format is known by the abbreviation APDU (xe2x80x9cApplication Protocol Data Unitxe2x80x9d). It is defined by the aforementioned ISO standard 7816-4. A command APDU is written as xe2x80x9cAPDU.commandxe2x80x9d, and a response APDU is written xe2x80x9cAPDU.responsexe2x80x9d. The APDUs are exchanged between the card reader and the smart card by means of a protocol specified by the aforementioned ISO standard 7816-3 (for example, in the character mode: T=0; or in the block mode: T=1).
When the smart card 2 includes a plurality of distinct applications, as illustrated by FIG. 2B, it is called a multi-application card. However, the terminal 1 is in a dialog with only one application at a time.
The selection of a particular application Ai is obtained with the aid of an APDU of the selection type (xe2x80x9cSELECTxe2x80x9d). Once this choice has been made, the APDUs that follow are routed through this application. A new xe2x80x9cAPDU SELECTxe2x80x9d causes the current application to be abandoned so that another one is then chosen. The software manager subset of the APDUs 201 makes it possible to choose a particular application Ai in the smart card 2, to memorize the application thus chosen, and to transmit and/or receive APDUs to and from this application.
To summarize what has just been described, the selection of an application Ai and dialog with it are done by exchanges of APDU orders. Let it be assumed that the applications Ai are conventional applications, hereinafter called GCAs (for Generic Card Application).
Given the above review, it should be noted that the smart card 2 cannot communicate directly with standard commercial navigators except by modifying their code.
Furthermore and above all, current smart cards, which moreover meet the standards described above, have a hardware and software configuration that no longer allows them to communicate directly with the internet. In particular, they cannot receive and transmit data packets by one or the other of the protocols used in this type of network. Hence it is necessary to provide an additional item of software, implanted in the terminal 1, generally in the form known as a xe2x80x9cplug-inxe2x80x9d. This item of software, which is identified by reference numeral 12 in FIG. 2A, acts as the interface between the navigator 10 and the card 2, and more specifically the electronic circuits 20 in this card 2.
The invention seeks to overcame the disadvantages of the methods and apparatus of the prior art, some of which have just been recalled, while meeting the needs that result.
According to the invention, the applications required for implementing the listing and locating protocols PE and PL, like the data characterizing the subscriber profile PA, are files that are preferably stored, entirely or in part, in the memories of a smart card, the executable files being standard applications of the aforementioned GCA type.
According to the invention, the smart card behaves like a webserver/client with regard to the terminal with which it is associated.
To attain this object, a specific communication protocol layer is provided in the smart card and its counterpart in the terminal. The term xe2x80x9cspecificxe2x80x9d must be understood to mean specific to the method of the invention. In fact, these communication layers, called specific communication layers, are non-specialized, regardless of the application in question. In particular, they are independent of the applications necessary for using the PE and PL protocols. They act only in the process of bidirectional data exchanges between the smart card and the terminal on the one hand, and the smart card and the network, on the other.
The specific communication software layer, known as xe2x80x9cintelligent agentsxe2x80x9d, make it possible in particular to convert protocols. The intelligent agents will hereinafter be called simply xe2x80x9cagentsxe2x80x9d. There are matched agents in the specific communication layers assigned to the terminal and the smart card, respectively. By the method of the invention, sessions between matched agents are established.
It will be noted that the method of the invention makes it possible to activate applications of a conventional type, that is, of the aforementioned GCA type, that are located in a smart card, without having to modify them in any way.
To do so, one or more particular intelligent agents called script translators are provided, which receive requests from a navigator and translate them into APDU orders that can be understood by the GCA application. In this way, a function similar to that also known as xe2x80x9cCGIxe2x80x9d in conventional webservers is implanted into the smart card. This function makes it possible to implement an application in the smart card using an internet protocol of the HTTP type.
These various applications enable the smart card, and more precisely the applications present in it, to communicate directly with a remote server connected to the internet network by using protocols of the internet type. The CGI function offered by the smart card for its part makes it possible to access applications associated with the listing and locating protocols PE and PL, respectively, and executing them, without requiring the presence of applications of a proprietary type in the terminal. Only a navigator, typically of the standard commercial type, is required.
In an advantageous characteristic of the invention, a particular application, which will be called a filter hereinafter, is implanted in the smart card. This involves a software entity which plays a role similar to that of a proxy. To do so, the aforementioned arrangements employing agents are used.
This arrangement enables to smart card to behave like a signaling protocol proxy (of the TCP type) and/or a data exchange protocol proxy (of the UDP type).
The value of a signaling proxy is to be capable of using a procedure of simple or mutual authentication between the caller and the called party, which can be useful for accepting communications, for instance. It also enables the negotiation of encryption keys. It furthermore allows negotiating an optimized routing path a priori, for example by guaranteeing a given transmission quality or an increased bandwidth.
The main value of a data exchange proxy is to be able to employ a robust procedure for encryption/decryption of information. A proxy also makes it possible to use a pricing procedure, based for example on the rate or the type of path negotiated beforehand.
These characteristics are highly suitable to meeting the perceived needs described above.
Hence the main subject of the invention is a method for managing transmissions of multimedia data via an internet-type network between a first subscriber system and a second subscriber system including at least one phase of signaling data exchange, via a signaling channel, with the aid of a predetermined signaling protocol, and a phase of exchanging said multimedia data via a data channel, with the aid of a predetermined communication protocol, characterized in that at least said first subscriber system includes a terminal provided with a web-type navigator and a smart card reader that cooperate via a smart card, said smart card including a first item of software, forming a specific communication protocol layer, and said terminal including a second item of software, forming a specific communication protocol layer and forming an interface with at least said web-type navigator; said first and second items of software further include at least a first autonomous software entity of the client type and a second autonomous software entity of the server type, said entities cooperating in such a way as to enable to establishment of bidirectional data exchange sessions between said terminal and said smart card, and that said smart card offers the function of a client/web server, and to enable to establishment of a bidirectional data exchange between the terminal of said first subscriber system and said second subscriber system via said internet-type network, said autonomous software entities communicating by means of predetermined protocol data units;
that it includes the embodiment, in said smart card, of an item of applications software of predetermined functional characteristics, known as a filter, which receives and/or sends protocol data units to and/or from said first and second autonomous software entities of the client and server type, respectively, which are included in said second specific item of software, the embodiment of said applications item being under the control of said autonomous software entity of the server type; and
that said filter cooperates with said autonomous software entities of said second specific item of software to open a session with said autonomous software entities of said first specific item of software in order to form a function known as xe2x80x9cproxyxe2x80x9d and to control predetermined characteristics of data exchanges that pass between said first subscriber system and said second subscriber system, via at least one of said signaling channels and/or data channels, during said phases of exchanging signaling data and/or multimedia data.
The subject of the invention is also a smart card for performing this method.